REMARKS 

Claims 1-3, 5-20, and 24-31 are currently pending. Claims 4 and 21-23 were previously 
cancelled. Claims 1, 24, 27, 29, and 30 are amended by present response without prejudice to 
subsequent presentation of these claims in a continuing or related application. Claims 1-3, 5-20, 
and 24-31 were rejected under 35 U.S.C. section 103(a) as being unpatentable over Mullendore 
et al. (U.S. Public. No. 2003/0185154) in view of Kaul et al. (U.S. Public. No. 2005/0050211). 
These rejections are respectfully traversed. 

The claims have been amended to facilitate prosecution, for example, to clarify the terms 
"initialize" and "OX_ID" and "RX_ID". These amendments are supported throughout the 
Specification, for example, at paragraph [0010] and paragraphs [0015] to [0018], among other 
places. While Applicants have made this amendment in an effort to expedite prosecution, the 
Applicants believe that the previously presented claims were fully patentable. The Applicants 
reserve the right to further prosecute these claims in the future. 

The present application generally describes a system for improving transmission of data, 
for example, performing a SCSI write operation, over a high latency network. Various 
embodiments in the Application describe a switch close to an initiator Host seeking to write to a 
target. In response to receiving the Host's write command, the switch anticipatorily sends 
transfer ready messages to the Host without waiting to receive transfer ready messages from the 
target. 'The apparatus includes a first Switch close to the initiator in a first SAN and a second 
Switch close to the target in a second SAN. In various embodiments, the two Switches are border 
switches connecting their respective SANs to a relatively high latency network between the two 

SANs During operation, the method includes the first Switch sending Transfer Ready 

(Xfr_rdy) frame(s) based on buffer availability to the initiating Host in response to a SCSI Write 
command from the Host directed to the target. The first and second Switches then coordinate 
with one another by sending Transfer Ready commands to each other independent of the target's 
knowledge. The second switch buffers the data received from the Host until the target indicates it 
is ready to receive the data." (Spec, para. [0010]) 

According to various inventive embodiments, switches carry out the above process by 
keeping track of specific transactions/exchanges between, for example, the host and the target, or 
the host and the first switch. In various embodiments, the OX_ID and RX_ID fields of a frame's 
header are used to keep track of different transactions. (Spec, para. [0010]) This is a novel 
aspect of the invention as switches do not ordinarily keep track of individual transactions 
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between a host and a target, and generally do not use the OX_ID and RX_ID fields. (Spec., para. 
[0016]) 

Independent claims 1, 24, 17, 29, and 30 recite various limitations relating to 
modification or initialization of OX_ID and RX_ID. The Examiner correctly points out that 
Mullendore does not teach or suggest "a frame having a header with an OX_ID or RX_ID" and 
does not modify or initialize either the OX_ID or RX_ID of the write command, or of the 
transfer ready command, as claimed. (Office Action, pages 4 and 11) The Examiner relies on 
Kaul to teach or suggest these recitations, citing paragraphs [0023] and [0024] of Kaul. 

However, Kaul fails to make any reference to the of OX_ID and RX_ID fields in these 

cited paragraphs or in any other sections of Kaul. Rather, the cited paragraphs describe "[a] 

method and apparatus to manage network addresses." (Kaul, Abstract) 

[0023] Whenever a call terminal inside LAN 110 wants to send a packet outside 
LAN 1 10, it forwards the packet to NAT 108. The IP header of the packet uses 
the local address of the call terminal for the source address of the packet. NAT 
108 receives the packet on its local interface, modifies the IP header of the packet 
to change the source address to the global address of LAN 110, and then sends the 
packet to network 112. 

[0024] Whenever a packet for a call terminal within LAN 1 10 is received by NAT 
108 at its global address interface, it uses the combination of global address and 
the port number at which it received the data to map it to a local address and port 
number for the destination call terminal within LAN 110. Before forwarding the 
packet to the destination call terminal within LAN 110, NAT 108 changes the 
destination address in the IP header from the global address to the local address of 
the destination call terminal in LAN 110. Once this is done, NAT 108 forwards 
the packet to the appropriate destination call terminal in LAN 110." 

The Examiner argues: "Similarly, Kaul discloses a data packet having routing header identifying 
a source and destination target; in the same way that a RX_ID is used to specifies [sic] a target. 
In other words, OX_ID and RX_ID are being interpreted as addresses for a source and a 
destination." (Office Action, page 4 and 11) But the Examiner's attempt to analogize the 
OX_ID and RX_ID fields to source and destination identifier fields misses the point that, in 
various embodiments, OX_ID and RX_ID are used to specify particular "exchanges" or 
"transactions" between the source and destination devices, not the devices themselves. As 
discussed in the Specification regarding particular embodiments: "For the hosts and targets 
within a network to keep track of the various transactions between each other, two fields are 
available in the Fibre Channel header for all SCSI Command, Data, Response, and Transfer 
Ready frames. The first field is called the Originator Exchange Identifier or OX_ID. The second 
field is called the Receiver Exchange Identifier or RX_ID." (Spec, para. [0015] (emphasis 
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added)) Accordingly, in various embodiments described in the Specification and that would be 
known to those with skill in the art, OX_ID and RX_ID are separate and distinct fields from the 
source and destination identifiers. (See also Figure 3, which discloses a diagram of a header 
field 20 that includes both OX_ID field 32 and an RX_ID field 34, as well as fields for S_ID and 
D_ID.) 

It is important to note that the pending claims achieve numerous advantages over the 
cited art. The cited references fail to disclose or suggest such advantages. As noted above, by 
modifying the OX_ID and/or RX_ID values, an intercepting switch may track exchanges. In 
addition, the cited references neither disclose nor suggest that an apparatus might need to track 
such exchanges in order to manage data transfers where transfer ready commands have been sent 
to the host before a transfer ready command has been received from the target. Thus, the 
techniques of the present invention intelligently operate to modify the OX_ID or RX_ID to, for 
example, allow the switch to "operate as a proxy for the target" as recited in independent claims 
24 and 27, among other claims. 

Furthermore, various independent claims also recite "initializing" the RX_ID or OX_ID 
fields. This claim element is also not taught by the cited references. It is true that some routers 
will sometimes translate source and destination addresses at NAT subnet boundaries as Kaul 
describes. However, even assuming these source and destination addresses were properly 
interpreted to be OX_ID and RX_ID values, which the Applicants strongly dispute, Kaul still 
does not "initialize" source and/or destination addresses at a switch. Applicants respectfully 
assert that initialization is not the same as modification, contrary to the Examiner's 
interpretation. Rather, initialization is performed to set an initial undefined value to one that is 
initialized. Applicant respectfully asserts Mullendore and/or Kaul fail to disclose or suggest the 
recitations relating to OX_ID and RX_ID noted above. These recitations are not taught or 
suggested, and cannot be assumed. 

While Mulldendore was not cited as teaching modifying or initializing "OX_ID" or 
"RX_ID", Muillendore was nevertheless reviewed for teachings relevant to the claimed 
invention. However, Mullendore does not overcome the deficiencies of Kaul. 

Based on the foregoing, it is submitted that the independent claims, and the claims that 
depend upon them, are patentable over Mullendore and Kaul, the cited references. Thus, it is 
respectfully requested that the Examiner withdraw the rejection of the claims under 35 USC 
§103. 
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CONCLUSION 

In light of the above remarks, the rejections to the independent claims are believed 
overcome for at least the reasons noted above. Applicants' Representative believes that all 
pending claims are allowable in their present form. If the Examiner has any questions or 
concerns for Applicants' Representative, the Examiner is encouraged to contact him at the 
number provided below. 

Respectfully submitted, 

Weaver Austin Villeneuve & Sampson LLP 

/Jeffrey K. Weaver/ 

Jeffrey K. Weaver 
Reg. No. 31,314 

Weaver Austin Villeneuve & Sampson LLLP 
P.O. Box 70250 
Oakland, CA 94612-0250 
(510) 663-1100 
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